sem: simplify generic parameter symbol handling #644
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Simplify type instantiation and logic related to generic parameters in general, by treating complex type expressions in generic contexts as generic expressions, with the symbols of generic parameters and parameters being bound during first-phase lookup already.
On the user-facing side of things, this fixes multiple long-standing issues with
undeclared identifier
errors for implicitly instantiated types. For example, the following previously failed:The
is
operator now also works properly inwhen
expression of generic objects. Anis
expression that was not the top-level one (this includesnot x is y
andx isnot y
) only checked for type equality and always evaluated to true when the right-hand side was aconcept
type.Another important thing to note is that type expressions used in the header of generic routines are, except for those used in range type constructors, now generic expressions, meaning that non-immediate templates/macros and
static
statements are only evaluated once the type is instantiated.On the compiler side of things, interactions with generic parameter symbols simplify, with a lot of conditional logic becoming obsolete. Instantiating types no longer requires opening a scope and adding all the bound types and static values as
skType
andskConst
symbols.One effect of the change is that generic parameter symbols are now always bound in type expression contexts, but never bound in generic procedure bodies.
Together, this should streamline generic parameter handling, making it more amendable to further changes / improvements in the future.